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10.  ABSTRACT  fCMNlMM  mi  rmmmrmm  MO*  H  ■•••••MY  M 

Three  computer  interface  systems  were  developed  and  tested  in  a  Navy  Pay/Person¬ 
nel  Administrative  Support  System  (PASS)  office.  These  three  systems  were  used  to 
nalyze  personnel  performance  times,  errors,  and  the  effects  of  computer  system 
arameters  on  error  rates.  This  report  describes  the  interface  systems,  discusses  their 
dvantages  and  limitations,  and  provides  recommendations  for  the  future  development  of 
i  source  data  entry  module  tor  use  in  personnel  office  information  systems. 


FOREWORD 


This  research  and  development  was  performed  in  support  of  program  element  number 
63707  (Manpower  Control  System  Development),  project  number  Z1170-PN  (Human 
?  Processing  of  Large  Information  Automated  Data  Bases),  under  subproject  Z1170-PN. 03 

!  (Improving  the  Accuracy  and  Usability  of  Automated  Personnel  Information  Systems). 

Sponsorship  was  provided  by  the  Deputy  Chief  of  Naval  Operations  (Manpower,  Personnel, 
i  and  Training).  Related  work  was  performed  under  program  element  number  62763 

I  (Personnel  and  Training  Technology),  work  unit  number  ZF 55- 521-001-022-03.03  (Fore- 

I  casting  New  Task  Requirements). 

't 

I  f 

I  The  objectives  of  this  effort  were  to  develop  and  test  working  models  of  an  interface 

i  device  that  would  permit  Navy  personnel  at  Pay/Personnel  Administrative  Support  System 

j  (PASS)  offices  to  compile  accurate  and  timely  inputs  to  the  host  personnel  information 

I  *  systems.  This  report  describes  these  interface  systems  and  discusses  their  test  perfor¬ 

mance  in  laboratory  and  PASS  office  applications. 
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SUMMARY 


Problem 

The  Manpower,  Personnel,  and  Training  Information  System  (MAPTIS)  and  the  Joint 
Uniform  Military  Pay  System  (JUMPS)  often  suffer  from  inaccurate  and  out-of-date  data. 
They  require  costly  labor-intensive  procedures  for  correction  of  errors.  There  is  a  need  to 
maintain  an  accurate,  timely,  and  low-cost  data  base  for  both  of  these  large  information 
systems  and  to  improve  operation  in  the  many  offices  that  provide  the  source  data. 

Objective 

The  first  objective  of  this  R&D  effort  was  to  develop  and  test  working  models  of  an 
interface  that  would  permit  personnel  at  Navy  Pay/Personnel  Administrative  Support 
(PASS)  offices  to  compile  accurate  and  timely  inputs  for  both  MAPTIS  and  JUMPS  while 
allowing  researchers  to  gather  data  needed  to  resolve  fundamental  human  engineering 
design  issues  pertaining  to  man/computer  work  stations.  This  interface  is  herein  called 
the  source  data  entry  module  (SODEM).  The  second  objective  was  to  develop  preliminary 
specifications  for  an  advanced  SODEM  incorporating  the  findings  of  the  research. 

Method 

Two  systems  were  developed  and  tested:  a  simple  stand-alone  microcomputer  system 
and  a  more  complicated  distributed-computer  system.  The  stand-alone  system  did  not 
include  a  local  data  base,  but  allowed  for  computer  checking  of  operator  inputs  and  for 
the  machine  printing  of  an  optical  character  reader  (OCR)  form  (the  same  form  that 
would  otherwise  be  produced  in  the  office  with  a  typewriter).  The  other  configuration 
was  a  micro/minicomputer  distributed  system  with  a  personnel  data  base. 

A  system  parameter  timing  study  (Williges  &  Wiiliges,  1982)  was  conducted  to 
examine  minimum  and  optimum  response  speeds,  work  sampling,  and  embedded  perfor¬ 
mance  measurement.  It  also  examined  operator  satisfaction  as  a  function  of  various 
timing  parameters  of  computer  systems. 

Results 


Because  of  the  slow  system  response  of  the  stand-alone  system,  it  was  used  very 
little  by  office  personnel.  Although  its  use  would  have  reduced  the  incidence  of  errors, 
supervisors  believed  that  the  error  reduction  would  not  compensate  for  the  additional 
time  required. 

The  distributed  system  met  with  favorable  user  acceptance,  largely  due  to  the  labor 
savings  it  made  possible.  The  distributed  system  used  a  faster  computer  for  the  main 
programs,  and  it  had  a  personnel  data  base  to  retain  information  previously  entered.  A 
low  error  rate  was  measured  for  data  entered  into  the  system. 

As  a  result  of  the  system  parameter  timing  study,  performance  prediction  equations 
were  generated  for  a  number  of  system  timing  parameters.  A  major  finding  was  that  user 
acceptance  seriously  deteriorated  for  system  delays  greater  than  5  seconds  or  for  echo 
rates  greater  than  0.75  seconds. 

Based  on  the  experience  gained  in  this  research,  preliminary  specifications  for  a 
practical  SODEM  were  developed. 
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mmmmM  sy*te&  to  aatisfactoiy  for  Improvement  of  accuracy,  timdinese,  and 
ft*,  and  it  a  uief ulvehide  for  continued  study  ©fpersonnel  office  Information 
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Accuracy  and  tlm^OdtO  can  ke  greatly  improved  over  the  previous  typewriter/OCR- 
fislrtt  malum,  HoweveSilt  Aould  ie  noted  that  some  information  cannot  be  checked 
automRtk^f.  fherefor^he  development  s  Improved  manual  extend  quality  control 
techniques  it  also  necessity. 

•  'h  .  ,  •  .  .  '  i.  • 

the  time  savings  md  qualitative  benefits  to  the  field  reporting  offices  must  be 
r* in  addition  tfc<*ccurocyani  tbnehness  of  data  inputs  to  the  host  computer 
system*  Field  office  tmMm  are 'understandably  major  factors  in  achieving  acceptance 
by  fleMeffice  personnel.;  ■ 


The  mdHtkfue  of  fhltaliitig  and  using  a  test  device  in  an  operating  Navy  personnel 
offiae  pmmed  «Het  tiveietthis  study,  but  added  high  overhead  to  the  research  project  in 
both  time  mid  money.  hMtfUtton,  test  devices  had  to  be  refined  to  a  highly  finished  and 
reiiabf»s|mi  to  induce  oyhraiionsl  personnel  to  use  tjhem.  For  these  reasons,  this  method 
ti  not  recommended  for tedtirw  marginal  or  high  risk  derigns. 


Recommendations  ’-v-  -r  — 

i.  ’  **<  ,e  :  ’-i  ••  ■  \  .V  ■  ,  >  -  j  '  .u 

1.  Uting  the  preK  Jneey  specifications  provided  in  this  report,  develop  an  advanced 
SOOEM  for  UBS  at  operational  Source  Oat*  System  (SOS)  sites.  Thjs  would  provide  a  way 
to  assess  the  vattdty  mdteee»affecti venese  ef  the  propomd  design  and  would  also  provide 
a  basis  for  enhendng  t^ddaimioreuftent  and  future  SDS  r  eeaordhptkgam*.  . 


2.  Perform  additfcfflil  study  of  the  query^rcsponse  dialog  to  improve  time  perfor¬ 

mance.  A  query-respensediMog  was  needed  to  aHow  the  peer  control  over  system 
functions  such  at  log  oity  review,  change;  print*,  and  the  like*  The  dialog  selected  proved 
to  be  slow  and  error  prone  (he*  it  provided  higher  overhead  time  than  the  authors 
desired).  Ima 

v.  in 

3.  Perform  additional  research  and  study  of  field  office  operation  so  that  SOOEM 
modules  for  other  offic^  applications  may  be  dmfiloped  that  will  enhance  the  cost 
effectiveness  of-  the  totSi  fr*iirce  data  system.  .  r  - .  \  *  J'  l .  .tvi 
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INTRODUCTION 


Problem 

The  Manpower,  Personnel,  and  Training  Information  System  (MAPTIS)  and  the  Joint 
Uniform  Military  Pay  System  (JUMPS)  often  suffer  from  inaccurate  and  out-of-date  data, 
and  they  require  costly  labor-intensive  procedures  for  correction  of  errors.  There  is  a 
need  to  maintain  an  accurate,  timely,  and  low-cost  data  base  for  both  of  these  large 
information  systems  and  to  improve  operation  in  the  many  offices  that  provide  the  source 
data. 

Background 

MAPTIS  and  JUMPS  are  computer-based  systems  that  support  management  decision 
making  in  the  Office  of  the  Chief  of  Naval  Operations,  the  Comptroller  of  the  Navy,  the 
Chief  of  Naval  Personnel,  the  Commander  of  the  Naval  Military  Personnel  Center 
(NMPC),  and  the  Commanding  Officer  of  the  Navy  Finance  Center  (NAVFINCEN), 
Cleveland.  NMPC  and  NAVFINCEN  are  the  central  design  authorities  for  MAPTIS  and 
JUMPS  respectively.  MAPTIS  and  JUMPS  entered  into  the  systems  by  personnel  at 
Personnel  Support  Detachments  (PSDs)  using  hand-typed  optical  character  recognition 
(OCR)  forms.  These  forms  are  then  sent  via  the  U.S.  postal  system  to  one  of  two  scanner 
sites  where  errors  are  discovered  at  a  rate  of  10  to  30  percent  when  they  are  machine- 
read.  More  than  150  man-years  are  expended  annually  in  attempting  to  correct  these 
errors  at  field  offices  and  OCR  scanner  sites.  In  addition  to  the  errors  entering  the  data 
base,  the  data  is  often  outdated  due  to  delays  of  up  to  90  days  that  occur  during  transit 
and  error  correction  procedures. 

Problems  of  accuracy  and  timeliness  in  large  personnel  information  systems  have 
been  a  matter  of  concern  for  some  time  due  to  the  costs  associated  with  incorrect  and 
out-of-date  personnel  information.  Many  of  these  problems  can  be  traced  to  the 
organization  and  function  of  the  data  entry  subsystem  and  even  to  the  operator-computer 
interface  itself.  Obermayer  (1977)  discussed  these  problems  and  their  sources  and 
presented  a  conceptual  framework  for  a  source  data  entry  module  (SODEM),  a  kind  of 
operator  front  end  for  the  data-base  system  providing  error  detection  and  correction 
functions  as  well  as  other  operator  aids.  Such  a  module  could  intercept  data  entry  errors 
before  they  entered  the  data  base,  reducing  the  editing  burden  on  the  main  system  and  the 
need  for  time-consuming  corrections. 

Three  interim  reports  documented  Obermayer's  ideas.  Bailey  (1979)  surveyed  the 
literature  and  identified  issues  that  must  be  addressed  in  SODEM  design.  Human  Factors 
Research  (1979)  identified  criteria  for  performance  evaluation.  Wylie  (1980)  provided  a 
SODEM  design  synopsis  based  on  function  allocation,  level  of  automation,  and  error 
detection  and  correction  methods. 

There  is,  then,  a  real  need  to  improve  operation  in  the  3000  offices  that  provide  the 
source  data.  The  Government  Accounting  Office  (GAO)  considers  the  problem  so  serious 
that  it  submitted  a  report  to  Congress  entitled:  The  Navy*s  Computerized  Pay  System  is 
Unreliable  and  Inefficient— What  Went  Wrong?  (GAO,  1980;.* 


General  Accounting  Office,  GAO  FGM5D-80-79,  Washington,  DC,  1980. 


1 


NMPC  is  currently  developing  a  source  data  system  (SDS)  for  MAPTIS  and  JUMPS 
that  will  provide:2 

1.  Adequate,  accurate,  and  timely  personnel  and  pay  information  for  developing 
and  implementing  the  manpower  plans  and  policies  of  the  Navy. 

2.  Automated  PSD  input  procedures  validating  and  editing  criteria,  and  inte¬ 
grated  pay  and  personnel  functions. 

3.  Accountability  of  PSD  originated  events  by  providing  an  automated  audit  trail. 

4.  An  extensive  information  support  capability  for  PSDs. 

5.  A  two-way  telecommunications  link  between  PSDs  and  the  host  computers  for 
MAPTIS  and  JUMPS. 

Of  course,  operator  interface  problems  are  not  unique  to  personnel  information 
systems,  but  are  shared  among  all  types  of  interactive  computer  systems.  While  the 
above  references  cite  the  general  human-computer  interaction  literature,  two  sources  are 
worth  noting  here.  Martin  (1973)  provided  a  rather  extensive  set  of  information  and 
guidelines  for  the  design  of  interactive  systems  and  his  book  serves  as  a  fundamental 
reference  in  interactive  system  research  and  development.  Schneiderman  (1980) 
reviewed  the  literature  prior  to  and  since  Martin's  work,  added  to  it,  and  extended  the 
concept  of  human  factors  in  computer  systems  to  the  area  of  software  development. 

Nor  is  the  notion  of  an  operator  front  end  module  entirely  new.  Hayes,  Ball,  and 
Reddy  (1981)  developed  such  a  system  for  an  electronic  mail  system.  Future  versions  of 
their  module  will  contain  adaptive  features  that  respond  to  the  specific  characteristics 
of  individual  operators. 

One  objective  of  the  work  covered  by  this  report  was  to  develop  and  test  working 
models  of  interface  devices.  The  most  critical  design  issues  included  (1)  large  informa¬ 
tion  system  communication  parameters  (e.g.,  system  response  time,  noise,  and  errors), 
(2)  rapid  data  entry  coupled  with  computer  error-checking  methods,  and  (3)  integration 
of  automation  into  all  levels  of  consolidated  personnel  offices.  Although  advanced 
automation  technology  is  already  available,  it  remains  to  be  determined  which  applica¬ 
tions  are  most  promising,  which  design  trade-offs  are  best,  and  whether  the  return  on 
investment  is  sufficient  to  warrant  specific  technological  applications. 

Objective 

The  first  objective  of  this  RicD  effort  was  to  develop  and  test  working  models  of  a 
SODEM  interface  that  would  permit  personnel  at  Navy  Pay/Personnel  Administrative 
Support  (PASS)  offices  to  compile  accurate  and  timely  inputs  for  both  MAPTIS  and  JUMPS 
while  allowing  researchers  to  gather  data  needed  to  resolve  fundamental  human  engineer¬ 
ing  design  issues  pertaining  to  man/computer  work  stations.  The  second  objective  was  to 
develop  preliminary  specifications  for  an  advanced  SODEM  incorporating  the  findings  of 
the  research. 


’Automated  Dv 


roc'  <ag  Selection  Office  (ADPSO)  RFP  No.  N66032-82-R-001 1. 


METHOD 


Two  configurations  of  a  man-computer  interface  were  developed,  installed,  and 
tested  in  an  operational  Navy  personnel  office  as  well  as  in  the  Navy  Personnel  Research 
and  Development  Center  (NAVPERSRANDCEN)  laboratory.  Both  devices  were  designed 
to  permit  Navy  personnel  at  PASS  offices  to  compile  accurate  and  timely  inputs  to  the 
MAPTIS  and  JUMPS  systems  while  also  allowing  researchers  to  gather  data  needed  for 
this  project.  Robinson,  Malone,  and  Obermayer  (1982)  reported  on  some  preliminary 
analyses  done  for  this  study. 

One  configuration  was  a  self-contained  office  data  entry  system  (SCODES)  using  a 
microcomputer  and  having  no  personnel  data  base.  This  configuration  allowed  computer 
checking  of  operator  inputs  and  the  machine  printing  of  the  same  OCR  form  that  would 
otherwise  have  been  produced  manually  on  an  electric  typewriter  having  an  OCR  font.  It 
was  a  minimal  configuration  consisting  of  a  cathode  ray  tube  (CRT)  display  and  a  small 
microcomputer  for  editing  and  error  checking. 

The  other  configuration  was  a  distributed  office  data  entry  system  (DODES)  using  a 
micro/minicomputer  system  that  included  a  personnel  data  base.  Studies  were  performed 
with  these  two  configurations  to  produce  data  on  errors,  timeliness,  and  user  acceptance. 

An  additional  study  (Williges  &  Williges,  1982)  was  conducted  to  investigate  computer 
system  timing  parameters.  (The  Williges  &  Williges  study  is  summarized  in  Appendix  B.) 
Timing  parameters  are  important  to  SODEM  design  as  well  as  to  the  assessment  of  the 
adequacy  of  host  computer  response  time;  consequently,  these  data  reflect  on 
performance  requirements  for  the  entire  system  and  establish  parameters  required  for 
successful  SODEM  application. 

! 

SELF-CONTAINED  OFFICE  DATA  ENTRY  SYSTEM  (SCODES) 

SCODES  was  developed  to  test  the  effectiveness  of  using  a  self-contained  system  to 
detect  errors  as  data  were  being  entered  into  the  MAPTIS  and  JUMPS  systems  and  to 
collect  and  analyze  detailed  information  on  the  quantities  and  types  of  errors  detected. 

Description  of  SCODES 

SCODES  represented  a  minimum  system  configuration  for  test  purposes  and  it  lacked 
a  supportive  data  base.  Error  checking  was  limited  to  tests  of  syntax  and  format  of 
information  being  entered- -no  comparison  with  previously  entered  information  was  pos¬ 
sible. 

SCODES  hardware  consisted  of  a  microcomputer  with  a  CRT  display,  a  detachable 
typewriter-like  keyboard,  a  disk  storage  device,  and  a  printer  capable  of  printing  OCR 
forms.  The  system  had  provisions  for  automatic  error  detection,  for  manual  error 
correction,  and  for  processing  the  OCR  form  used  for  military  pay  actions  (Figure  1). 
This  form  was  selected  because  it  had  a  higher  documented  error  rate  than  any  other  OCR 
form.  The  system  also  automatically  recorded  information  on  detected  errors  for  later 
analysis. 

The  software,  written  in  BASIC,  prompted  the  user  by  means  of  a  question/menu 
format.  The  numbered  blocks  appearing  on  the  form  were  presented  on  the  CRT  screen 
along  with  prompts,  cues,  and  detailed  explanations.  The  REASON  FOR  CHANGE  block 
was  known  to  be  the  major  source  of  errors  and  an  extensive  menu  was  incorporated  into 
the  software  to  help  in  the  selectior  of  entry  codes.  When  data  entry/correction  tasks 
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were  completed,  the  information  was  automatically  transcribed  onto  the  OCR  form.  An 
option  for  repeated  printing  of  the  OCR  form  was  available  to  handle  those  cases  where 
the  form  did  not  print  properly  the  first  time. 


Error-checking  software  ensured  that  all  necessary  (and  no  unnecessary)  entries  were 
made.  Other  checks  were  made  for  appropriate  alpha,  numeric,  special  characters,  and 
proper  format  of  data.  In  each  case,  error,  were  presented  to  die  data  entry  operator  for 
immediate  correction  at  the  time  (and  point)  of  entry.  Based  on  previous  error  counts 
with  the  existing  manual  data  entry  system,  the  error  checks  were  expected  to  detect 
more  than  two-thirds  of  the  total  errors:  especially  those  errors  that  were  most 
significant.  Data  on  errors  were  automatically  recorded  for  subsequent  statistical 
analysis. 

Field  Office  Test 


Approach 

Personal  from  the  Personnel  Support  Detachment  (PSD),  Point  Loma  were  given 
indoctrination  and  training  to  prepare  them  for  operation  of  the  system.  This  training 
consisted  of  demonstrations  followed  by  hands-on  sessions  for  each  subject.  The  system 
was  used  in  place  of  the  standard  electric  typewriter  for  preparing  3060  forms  as  part  of 
the  normal  office  routine. 

Results 


The  principal  test  result  was  that  the  SCODES  was  used  very  little  by  office 
personnel.  PSD  personnel  stated  that  their  main  reason  for  not  using  the  SCODES  system 
was  that  they  perceived  it  to  be  slower  than  using  a  standard  electric  typewriter. 
Subsequent  experimentation  verified  that,  in  fact,  additional  processing  time  was  required 
by  SCODES.  While  the  use  of  SCODES  would  have  reduced  the  incidence  of  errors,  the 
supervisors  believed  that  error  reduction  was  not  adequate  compensation  for  the 
additional  time  required  in  preparing  the  form.  Office  personnel  did  not  perceive  that 
they  had  accrued  any  benefit  from  using  the  syste*  i.  Therefore,  the  PSD  Point  Loma  test 
was  terminated  early,  and  the  system  was  moved  to  the  NAVPERSRANDCEN  laboratory 
for  further  tests  in  preparation  for  development  of  a  system  that  would  overcome  the 
shortcomings  of  SCODES. 

Laboratory  Test 

Approach 

In  addition  to  ensuring  that  SCODES  would  be  used,  moving  the  experiment  back  into 
the  NAVPERSRANDCEN  laboratory  environment  allowed  for  controls  that  could  not  be 
imposed  in  the  field  (e.g.,  control  of  lighting  and  interruptions).  Conducting  the 
experiment  in  the  laboratory  also  allowed  the  experimenter  to  monitor  the  experiment 
personally  as  it  was  being  performed. 

Three  Navy  personnelmen  (PNs)  stationed  at  NAVPERSRANDCEN  and  a  NAVPERS¬ 
RANDCEN  professional  were  used  as  subjects  for  the  laboratory  experiment.  SCODES 
and  a  standard  electric  typewriter  were  used  by  the  test  subjects  to  prepare  NAVCOMPT 
3060  OCR  forms  in  the  laboratory  experiment.  All  subjects  were  experienced  in  the 
preparation  of  OCR  forms  using  a  standard  electric  typewriter  and  were  trained  in  the  use 
of  SCODES.  The  subjects  were  tested  on  both  methods  shortly  after  the  orientation 
period  and  again  after  6  weeks'  experience  with  the  system.  Each  subject's  experience 


was  labeled  "inexperienced"  (less  than  1  week)  and  "experienced"  (6-9  weeks).  The  data 
from  these  tests  are  summarized  in  Table  1. 


Table  1 

Preparation  Time  (minutes)  for  NAVCOMPT  Form  3060 


SCODES 

OCR  Typewriter 

Tasks 

Inexp 

Exp 

Inexp 

Exp 

Single  entry 

Data  entry 

2.6 

2.1 

l'i 

Edit 

.5 

.4 

w 

K 

Print 

3.0 

.8 

D 

D 

— 

— 

— 

— 

Total 

6.1 

3.3 

1.5 

1.8 

Multiple  entries 

Data  entry 

7.8 

5.9 

3-| 

"'I 

Edit 

1.5 

.6 

w 

h 

Print 

2.2 

1.5 

D 

Total 

11.5 

8.0 

3.9 

4.3 

Editing  performed  after  the  form  is  typed. 
bData  entry  and  printing  performed  concurrently. 


Results 


The  individual  and  total  time  comparisons  indicated  that  using  SCODES  required 
more  time  than  using  the  standard  electric  typewriter.  The  situation  was  particularly 
unfavorable  to  SCODES  when  a  single  transaction  for  one  member  of  the  service  was 
recorded.  In  this  case,  the  data  could  be  entered  in  approximately  half  the  time  when 
using  the  standard  typewriter.  Even  forms  with  multiple  entries  were  produced  faster 
(80%  of  the  computer  time)  when  using  the  typewriter.  In  addition  to  the  entry  time,  the 
operator  using  the  SCODES  was  required  to  display  the  completed  form  on  the  CRT  for 
review,  edit,  and  then  print  the  final  form.  However,  when  errors  were  discovered  on 
forms  prepared  using  the  typewriter,  the  form  had  to  be  completely  retyped,  incurring 
additional  time.  Measurement  of  the  manual  task  did  not  include  review  and  edit  time  by 
the  data  entry  operator  or  supervisory  personnel.  No  data  are  available  for  review  time  in 
the  office.  Interviews  with  experienced  personnel  indicated  that  review  time  can  vary 
widely  with  different  offices  and/or  reviewers.  However,  the  error  checking  features 
were  not  considered  to  be  an  offsetting  positive  factor  by  the  test  subjects  and 
supervisory  personnel. 


f  ■  _  ■  «>  i  i.'  r1^ 


Conclusions  from  Testing  of  SCOPES 

Based  upon  results  of  the  office  and  laboratory  tests  of  SCODES,  it  was  determined 
that: 


1.  The  use  of  a  BASIC  interpreter  as  a  programming  language  is  unacceptable 
because  it  it  too  slow. 

2.  A  system  with  more  capability  than  the  microcomputer  used  for  SCODES  is 
required. 

3.  Errors  can  be  significantly  reduced  by  utilizing  stored  information  to  avoid  re¬ 
typing  unchanged  information  each  time  a  form  is  updated. 

4.  An  automated  device  for  data  entry  must  benefit  the  office  entering  the  data  as 
well  as  provide  an  acceptable  end  product  to  the  receivers  of  the  data  (NMPC  and 
NAVFINCEN). 


DISTRIBUTED  OFFICE  DATA  ENTRY  SYSTEM  (DODES) 

It  was  clear  from  the  experience  with  SCODES  that  a  successful  office  data  entry 
system  would  have  to  reduce  the  office's  work  load  or  increase  its  productivity.  It  should 
also  reduce  errors  and  have  the  potential  for  electronic  submission  of  data.  Electronic 
data  submission  would  greatly  reduce  the  problems  and  time  associated  with  printing  and 
maintaining  paper  forms.  It  would  also  provide  other  benefits,  such  as  the  compilation 
and  printing  of  routine  management  reports.  It  is  to  these  ends  that  an  improved  system, 
the  distributed  office  data  entry  system  (DODES),  was  developed  to  collect  performance 
measurements  and  design  data  unobtrusively. 

Description  of  DODES 

While  SCODES  was  designed  to  prepare  the  NAVCOMPT  3060  form,  which  is  a  short 
form  but  one  which  has  a  high  accompanying  error  rate,  DODES  was  designed  to  prepare  a 
long  form  that  requires  tedious  preparation:  the  Dependency  Application/Record  of 
Emergency  Data  form,  NAVPERS  1070/P602R,  also  commonly  referred  to  as  the  "page  2" 
(Figures  2  and  3). 

To  reduce  computer  response  time,  a  distributed  computer  system  was  implemented. 
A  microcomputer  was  used  in  the  office  to  control  input/output  0/0)  from  the  operator  in 
response  to  commands  from  a  remote  minicomputer.  The  display  formats  of  prompts 
(e.g.,  requests  for  data)  were  stored  on  a  "floppy  disk"  and  were  presented  on  the 
operator's  CRT  upon  command  from  a  remote  minicomputer.  The  microcomputer  also 
performed  the  operations  necessary  to  collect  data  on  operator  response  and  typing  times. 
The  microcomputer  then  transmitted  these  data  back  to  the  minicomputer.  Data  storage 
and  the  bulk  of  the  computation,  edit  checks,  and  control  functions  were  performed  by 
the  minicomputer.  All  of  the  logic  necessary  to  carry  out  the  processing  of  a  Record  of 
Emergency  Data  form  was  under  control  of  the  minicomputer.  The  minicomputer 
controlled  all  of  the  processing  requests  to  the  microcomputer  system  for  data  input,  the 
editing  of  data  for  correct  format  and  content,  the  formatting  of  data  for  storage  and 
retrieval,  the  formatting  of  data  for  printing  of  OCR  forms  and/or  display  on  the  CRT, 
and  the  retrieval  of  existing  records  for  review  and/or  update. 
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DEPENDENCY  APPl I  CAT I ON / RECORD  OF  EMERGENCY  DATA 


2. SHIP  OR  STATION 

USS  TOWERS  006  M 


S. NAME  OF  SPOUSE 


ANN  LYNN  CURRY  LOGAN 


•.PLACE  OF  MARRIAGE  (CITY  &  STATE  OR  COUNTRY) 

CHARLESTON i  UV 


IS.  NAME  OF  CNILO  OR  DEPENDENT 

PETER  SAMUEL  LOGAN 


If.  ADDRESS  (INCLUDE  NAME  OF  CUSTOOIAN  IF  OTHER  THAN  CLAIMANT) 

NANCY  P-  LOGAN  LEG  GONi  SIM  REESE  RO  *  ERIE  i  PA  11510 


It. NAME  OF  CHILD  OR  DEPENDENT 


21.  ADDRESS  (INCLUDE  NAME  OF  CUSTOOIAN  IF  OTHER  THAN  CLAIMANT 


).  NAME  OF  CHILD  OR  OEPENOENT 


2«. ADDRESS  (INCLUDE  NAME  OF  CUSTOOIAN  IF  OTHER  THAN  CLAIMANT) 


2«. NAME  OF  CHILO  OR  DEPENDENT 


SO.  NEXT  OF  KIN  OF  SPOUSE  (NOT  HUSOAMO, 

iL'tct'  flWSWlHERS 


St. RELATIONSHIP 

SISTER 


SO. SENCF ICI AAV(S)  FOR  GRATUITY  PAY  (NO 
SPOUSE  OR  CNILO  SURVIVING) 

SYLVIA  PAULA  LOGAN 


•4. IIFC  INSURANCE  OA T A  (NAME  OF  CO.)  (00 
NtH  INI  Hint  soil) 

PRUDENTIAL  LIFE 
INSURANCl._£fi_: _  _ 

f  **.  AIL  I G  l  ON 


73. NAME  OF  DESIGNATOR  (LAST ,  FIRST,  MIDDLE) 

LOGAN".  LEONARD  ALBERT 


«(.r«iicr  HuMtr 


M33510 


)l  or  r»»cs 

1 


\mmm 


oercNOtNcv  *rrnc*Tiot./»tcoi»o  of  ckersckcy  data  navkm  toro/oo*  (oev.  7-7*)  faat  ii 


Figure  2.  Front  page  of  NAVPER5  1070/P602R. 
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NAVPtHS  lon/HI  (MV.  7-11)  (PANT  II)  (MW) 


I 


J*. 

aaiuaaa 

Ik 

CHILD  SUPPORT  *50  PER  HONTH  COURT  ORDER 

Sk  20% 

TO  EX-HIFE  AS  LECAL  GUARDIAN- 

kl  MV  2S311 

3k 

CONTRIBUTION  0100  PER  MONTH. 

SI 

ssam 

S3 

SYLVIA  PAULA  LOGAN 

51 

k23  HILLVXEM  DR  a  CHARLESTON-  MV  2S311 

ss 

MOTHER 

CCRT I f I  CAT  I OM  OF  PtIIONATOM 


t  kaaa  raaiaaaO  aka  lata  aataral  w  tkia  fara  aa4  aaraify  tkat  ia  ia  aarraaa. 


Eaacaaa  a  aaa  NAVPtMS  1070/kt!  if  aka  lau  ia  aaa  aartaaa. 


Figure  3.  Back  page  NAVPER5  1070/P602R. 
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Programming  was  done  in  assembly  language  on  the  microcomputer,  and  in  a  high¬ 
speed,  high-level  language  on  the  minicomputer.  The  microcomputer  was  a  Futuredata 
8/16  based  on  an  Intel  8080  microprocessor;  the  minicomputer  was  a  Digital  Equipment 
Corporation  PDP  11/45  running  under  the  UNIX  operating  system  and  using  C  as  its 
primary  programming  language.  The  minicomputer  also  incorporated  a  large  disk 
memory,  permitting  the  storage  of  completed  602  forms  for  all  personnel  serviced  by  a 
PSD.  It  also  permitted  the  modification  of  forms  without  completely  reentering  all 
information  as  is  required  using  the  current  typewriter  OCR  method.  Additionally,  the 
DODE5  data  base  was  available  for  printing  summary  reports,  providing  audit  trails,  and 
for  other  office  needs. 

Laboratory  Test 

Prior  to  installing  DODES  in  the  field,  tests  were  performed  in  the  NAVPERS- 
RANDCEN  laboratory  under  controlled  conditions.  A  direct  comparison  with  the  current 
manual  method  was  made. 

Method 

Equivalent  sets  of  simulated  "page  2"  personnel  data  were  created  for  use  in  both  the 
manual  and  DODES  tasks.  The  data  to  be  entered  were  carefully  matched  for  the 
experiment  so  that  the  number  of  characters  and  finger/keyboard  usage  were  balanced 
across  experimental  treatments.  Seven  men  and  three  women  were  selected  from  a  pool 
of  Navy  personnelmen  (PN  rating)  and  Navy  civilian  clerical  personnel.  All  were 
experienced  typists  familiar  with  Navy  procedures  and  the  preparation  of  Navy  OCR 
forms.  The  subjects  were  given  brief  written  instructions  that  explained  the  experiment, 
and  a  users'  manual  was  reviewed  with  each  operator.  Each  operator  was  then  given  the 
opportunity  to  practice  completing  "page  2s"  on  the  DODES  before  participating  in  the 
controlled  experiment. 

DOPES  task.  Each  subject  filled  out  two  separate  page  2s  using  the  computer  (80 
blocks  on  each  form).  After  the  forms  were  completed,  subjects  were  asked  to  make  two 
changes  on  a  page  2  form  that  was  already  on  file  in  the  computer  data  base.  The 
following  measurements  were  recorded  automatically  by  the  computer  for  each  task 
completed  by  each  subject: 

1.  The  elapsed  time  between  the  time  a  query  was  presented  on  the  CRT  and  the 
time  the  subject  responded  with  a  keystroke. 

2.  The  elapsed  time  between  the  first  keystroke  response  to  a  query  and  the  next 
carriage  return  (carriage  returns  signaled  the  completion  of  tasks). 

3.  The  number  of  times  that  the  backspace  key  was  struck  (a  measure  of  the 
number  of  errors  detected  and  corrected  by  the  subject  (commonly  referred  to  as 
"typos"/"strikeovers")). 

4.  Errors  detected  by  the  computer  and  called  to  the  operator's  attention  for 
immediate  correction. 

Manual  task.  The  mutual  task  consisted  of  typing  two  forms  on  an  IBM  Seiectric 
typewriter  with  an  OCR  font.  The  subjects  were  required  to  fill  in  blocks  1-46  and  67-76 
on  the  front  page  with  carbons  inserted  for  copies  2  through  5,  remove  the  form  from  the 
typewriter,  reinsert  copies  4  and  5,  and  fill  in  blocks  47-66.  The  backs  of  Part  I  and  Part 
II  had  to  be  filled  out  separately  (turning  the  forms  over,  reversing  their  order  and 
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reinserting  the  carbon  paper)  since  the  back  of  the  form  contained  additional  information. 
A  stopwatch  accurate  to  a  tenth  of  a  second  was  used  to  time  the  subjects  on  each  form. 
Errors  were  broken  down  into  two  categories:  (1)  detected  and  corrected,  and  (2) 
undetected  (i.e.,  errors  that  would  have  gone  into  the  data  base). 

Results 

A  summary  of  the  timing  data  is  presented  in  Table  2.  The  amount  of  time  required 
to  enter  a  complete  form  was  not  significantly  different  for  either  method;  however,  a 
change  could  be  produced  using  the  computer  in  about  l/4th  the  time  since  the  manual 
method  required  completely  retyping  the  form.  Clearly,  the  keystrokes  "saved"  by  using 
the  computer  supported  system  can  be  a  significant  benefit  to  the  office  for  this  task. 


Table  2 

Time  Required  to  Complete  or  Change  Dependency  Application/Record 
of  Emergency  Data  Forms  NAVPERS  Form  1070/P602R 


Tasks  (minutes  per  form) 

Measures 

DODES 

Entering 

New  Form 

Changing 
a  Form* 

Manual 

Entry 

Entry  and  Printing: 

Mean 

14.56 

4.13 

16.46 

Median 

14.20  . 

4.11 

14.60 

Mode 

11.18,  17.50° 

4.11 

10.38 

Variance 

8.75 

2.34 

42.26 

Standard  Deviation 

2.96 

.58 

6.50 

Entry  Time  Mean 

12.20 

2.20 

_c 

Printing  Time  Mean 

2.40 

1.89 

_c 

‘h'wo  changes  made  to  a  completed  form  in  the  data  base  file. 
bBimodal 

cNot  applicable— Entry  and  printing  occurred  concurrently. 


Table  3  indicates  that  the  number  of  undetected  errors  that  would  have  entered  the 
Navy's  master  data  base  was  significantly  greater  for  forms  filled  out  manually  than  for 
forms  completed  using  DODES.  Operators  detected  and  corrected  significantly  more 
errors  when  entering  the  forms  on  the  computer  system.  The  error  rate  for  forms  in  the 
DODES  data  base  was  0.53  errors  per  form;  virtually  no  undetected  errors  would  have 
entered  the  MAPTI5/3UMPS  data  base. 
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Table  3 


Error  Rates  for  DODES  and  Manually  Prepared  Dependency  Application/Record 
of  Emergency  Data  Forms  NAVPERS  Form  1070/P602R 


Tasks 


Computer  Data  Change3  Manual 

Entry  using  Computer  Entry 

Type  of  Error  Mean  %  Mean  %  Mean  % 


Operator  Detected/Corrected 

8.23 

87 

.10 

33 

3.00 

70 

Computer  Detected/Operator  Corrected 

.70 

7 

.20 

67 

— 

— 

Total  Detected  Errors 

8.93 

94 

.30 

100 

3.00 

70 

Undetected  Errors** 

.55 

6 

.00 

0 

1.30 

30 

Total  Errors 

9.50 

100 

.30 

100 

4.30 

100 

^wo  changes  made  to  a  completed  form  in  the  data  base  file. 
^Errors  that  would  have  been  transmitted  to  the  data  base. 


While  the  number  of  errors  entering  the  data  base  when  DODES  was  used  was 
minimal,  examination  of  Table  3  reveals  a  paradox.  The  operators  using  DODES  made 
more  errors  than  did  the  operators  using  the  current  manual  system.  Using  DODES 
evidently  allowed  the  operators  a  less  stressful  working  environment.  They  knew  that, 
when  they  made  a  mistake,  they  could  backspace  and  overtype  an  error  with  the 
correction,  a  luxury  not  always  afforded  in  the  manual  system.  Also,  they  knew  that 
errors  detected  by  DODES  would  be  presented  for  immediate  correction  and  those 
detected  by  them  at  a  later  time  could  be  corrected  without  having  to  completely  reenter 
all  of  the  data  contained  on  the  form. 

Field  Office  Test 

Method 

DODES  was  used  for  data  entry  of  complete  Records  of  Emergency  Data  (NAVPERS 
FORM  1070/P602R)  by  person nelmen  at  the  Point  Loma  PSD  and  by  university  students 
and  civil-service  personnel  employed  by  NAVPERSRANDCEN.  As  a  result  of  these 
efforts,  a  substantial  data  base  was  created  for  more  than  halt  of  the  total  number  of 
personnel  served  by  the  Point  Loma  PSD  (the  data  discussed  in  this  report  are  based  on 
1123  forms;  however,  data  were  entered  for  1891  personnel).  This  data  base  could  be  used 
for  reporting  changes  as  they  occurred  (with  substantial  time  savings  compared  to  the 
current  method  of  completely  retyping  a  form  each  time  a  change  is  required).  However, 
most  of  the  activities  reported  here  were  associated  with  creation  of  complete  records 
(and  the  correction  of  errors  made  while  creating  these  records).  In  addition  to  providing 
research  data,  this  data  base  was  used  as  a  means  for  updating  individual  records  and  for 
conducting  periodic  reviews  for  the  accuracy  of  existing  records. 
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Distribution  of  Time 


A  little  less  than  one-half  of  the  time  was  used  for  activities  other  than  direct  data 
entry?  however,  only  about  one-tenth  of  the  total  time  was  used  for  administrative  system 
functions  such  as  selecting  and  controlling  the  sequencing  of  data  entry.  The  percentages 
of  time  used  for  various  tasks  in  preparing  the  Emergency  Data  form  are  listed  below: 

1.  Add  new  records,  53  percent. 

2.  Print  records,  23.2  percent. 

3.  Record  retrieval,  11.8  percent. 

4.  Administrative  time,  7.7  percent. 

5.  Change/modify  records,  4.3  percent. 

6.  Display/view  records,  less  than  1  percent. 

Analysis  of  Data  Entry  Time 

As  the  operator  entered  data  at  the  computer  terminal,  measurements  were 
automatically  recorded  on  operator  response  time  to  a  query  (time  from  display  of  a  query 
on  the  CRT  until  the  operator  depressed  the  first  key),  the  time  the  operator  spent 
waiting  on  th»  system,  and  the  number  of  times  the  back  space  key  was  used  (an 
indication  of  a  possible  operator-detected  error).  Data  were  also  collected  fin  the  number 
and  types  of  errors  detected  by  the  system  and  flagged  for  correction  by  the  operator.  A 
tabulation  of  the  time  measurement  for  each  block  of  the  Emergency  Data  form  is 
presented  in  Table  4. 

These  data  are  grouped  by  type  of  response  in  Table  5.  It  is  apparent  that  the  largest 
factor  affecting  data  entry  time  is  the  length  of  the  entry;  that  is,  longer  typing  time, 
longer  total  time,  and  increased  use  of  the  back  space  results  when  names  and  addresses 
must  be  entered.  Otherwise,  there  are  few  apparent  differences. 

Analysis  of  Errors 

An  analysis  of  errors  detected  by  the  system  showed  that  approximately  60  percent 
of  all  errors  took  place  during  data  entry  (Table  6).  The  remainder  occurred  when  the 
operator  responded  inappropriately  to  system  prompts  such  as  "enter  password  and  user 
log-in  name."  Further  effort  should  be  directed  at  reducing  these  errors. 

Additional  analyses  of  data  entry  errors  are  presented  in  Tables  7  and  8.  Table  7 
presents  error  rates  by  block  number,  while  Table  8  presents  an  error  count  by  block 
number  and  specific  type  of  error.  It  is  not  clear  why  dates  were  wrong  more  often  in 
some  blocks  than  in  others,  or  why  some  yes/no  responses  gave  such  difficulty. 

Timing  Parameters 

A  system  timing  parameter  study  was  performed  by  Williges  and  Williges  (1982)  as 
part  of  this  work.  This  study,  which  is  summarized  in  Appendix  B,  indicated  that  operator 
performance  begins  to  degrade  when  the  system  response  time  (the  time  the  operator  is 
waiting  on  the  system)  is  greater  than  4  seconds.  The  system  response  time  for  the 
DODES  study  was  judged  acceptable  by  the  users. 


Tablet 


Performance  Measurement  Data  For  Record  of  Emergency  Data 
(NAVPERS  Form  I070/PM2R)  (Tabulated  by  block) 


' ; 

block 

No.  of 
Timet 

Time  (S< 

Operator 

xonOt) 

Operator 

Total 

Entries 

with 

back- 

maces 

No.  Entry  Requested 

Used 

Response  Typing 

Waiting 

Time 

(%> 

Table  5 


Performance  Measurement  Data  for  Record  of  Emergency  Data  (NAVPERS 
Form  1070/P602R)  (Grouped  by  Similar  Blocks  of  Data) 


Block 

Numbers 

Type  of  Entry 

No.  of 
Times 
Used 

Operator 

Response 

Time  (Seconds) 

Operator 
Typing  Waiting 

Total 

Entries 

with 

Back¬ 

spaces 

(%) 

3,  12, 
17,  22, 
27,  32, 
35,  38, 
39,  43, 

81 

Single  character 
alpha  response 

4140 

1.5 

0.6 

0.5 

2.6 

1.7 

40,  44, 

75 

Single  number 
from  table 

681 

1.3 

0.5 

0.5 

2.3 

2.6 

5,  13, 
18,  23, 
28,  33 

36,  47, 
50,  53, 
57,  60 

64 

Names 

4546 

1.8 

8.5 

0.7 

11.0 

31.0 

6,  9, 

14,  19, 
24,  29, 
35,  41, 
45,  82, 

83 

Dates  (7  character 
format) 

2554 

2.1 

3.7 

0.5 

6.3 

4.8 

8,  11, 
16,  21, 
26,  31, 
34,  37, 
42,  46, 
48,  51 

54,  58, 
61,65 

Addresses  (free 
format) 

2746 

2.6 

14.8 

0.9 

18.3 

43.7 

15,  20, 
25,  30 

1-2  position  number  612 
from  table 

1.3 

0.5 

0.8 

2.6 

2.0 

49,  52, 
55,62 

Relationship  (not 
from  table) 

1667 

1.4 

2.4 

0.5 

4.3 

16.5 

56,  59, 
63 

1-2  digit  number 
(not  from  table) 

1807 

1.1 

1.1 

0.6 

2.8 

2.4 

15 


Error 

Count® 


Percent 


Type  of  Entry 


Data  Entry: 


Data  entry  to  block  on  form 

500 

59.7 

Entry  of  SSN 

14 

1.7 

System  Prompts: 

User  log-in  name 

146 

17.4 

Select  block  to  change 

62 

7.4 

Branch  in  program 

52 

6.2 

Select  type  of  form 

30 

3.6 

Verify  return  code 

25 

3.0 

Line  printer  select 

8 

1.0 

Total 

837 

100.0 

Table  7 


Error  Rate  by  Block  Number 


Block 

Number® 

Error 

Rate0 

Contents  of  Block 

14 

.17 

Date  of  birth  (// 1  child) 

47 

.16 

Name  of  other  person  to  be  notified 

41 

.14 

Date  of  dissolution  of  previous  marriage 

82 

.14 

Date  of  SGLI 

17 

.05 

Spouse  dependent  (yes/no) 

65 

.05 

Address  of  insurance  company 

55 

.04 

Relationship  of  beneficiary 

9 

.04 

Date  of  marriage 

36 

.04 

Name  of  mother 

8 

.04 

Place  of  marriage 

10 

.04 

Citizenship  of  spouse 

39 

.03 

Previously  married  (yes/no) 

50 

.03 

Name  of  next  of  kin  of  spouse 

80 

.03 

Name  of  approving  officer  and  title 

83 

.03 

Date  of  last  certification  (review  of  form) 

67 

.02 

Religious  preference 

43 

.02 

Was  spouse  previously  married?  (yes/no) 

53 

.02 

Name  of  beneficiary 

60 

.02 

Beneficiary  for  gratuity  pay 

70 

.01 

Rank/rate 

^or  those  blocks  with  more  than  10  errors.  (Sample  consisted  of 
1123  forms.) 

^Relative  frequency  with  which  an  error  was  made  when  entering 
data  for  block. 


Li 
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Table  8 

Error  Count  by  Block  Number  and  Error  Type 


Error  Error 

Block  Description  Counta 

14  Incorrect  month~not  3 an.,  Feb.,  etc.  20 

80  No  selection  or  entry  made  for  name  of  certifying  officer  20 

55  Character  other  than  alpha  or  space  for  relationship  of  20 

beneficiary  for  unpaid  pay  and  allowances 

39  Entry  other  than  y  or  n  for  "were  you  previously  married?  19 

14  Year  not  numeric,  DOB  of  1st  child  15 

17  Entry  other  than  y  or  n,  child  dependent?  15 

67  Religion  code  not  in  table  13 

8  Character  other  than  alpha  or  space,  place  married  12 

14  DOB  of  1st  child  later  than  effective  date  of  form  11 

36  Less  than  two  word  name  of  place  where  spouse's  previous  1 1 

marriage  was  dissolved. 

43  Other  than  yorn,  "was  spouse  previously  married?"  1 1 

55  Character  other  than  alpha  or  space,  relationship  of  1 1 

beneficiary  for  unpaid  pay  and  allowances 

50  Less  than  given  and  surname  entered  for  next  of  kin  of  spouse  10 

9  Date  of  marriage  later  than  effective  date  of  form  10 

35  Dther  than  y  or  n  entered,  dependent  father  9 

59  Nonnumeric  entry,  percent  missing  status  allotment  9 

5  Character  other  than  alpha  or  space,  name  of  spouse  9 

15  Not  on  list  or  not  numeric  9 

70  Rank  or  rate  does  not  match  list  9 


^or  entries  with  more  than  10  errors  in  1123  forms. 


PRELIMINARY  SPECIFICATIONS  FOR  A  PROPOSED  SOURCE 
DATA  ENTRY  MODULE  (SODEM) 

This  section  provides  a  functional  description  of  the  components  of  a  proposed  source 
data  entry  mddule  (SODEM). 

Design  Goals 

The  design  goals  for  the  SODEM,  derived  from  the  experimental  results  and  the 
researchers*  exposure  to  personnel  office  operations,  are  to: 

1.  Increase  data  accuracy  through  good  system  design  and  automated  error  detec¬ 
tion  and  correction. 

2.  Improve  data  timeliness  through  increased  emphasis  on  local,  as  opposed  to 
centralized,  error  detection  and  correction. 

3.  Provide  adaptive  features  that  automatically  adjust  to  the  user's  level  of  skill. 
Design  Philosophy 

In  a  rapidly  changing  technological  environment,  systems  must  be  flexible  and 
expandable.  At  the  same  time,  they  must  respond  rapidly  to  user  inputs.  To  obtain  all  of 
these  characteristics  in  the  proposed  SODEM,  a  design  philosophy  based  on  modularity  and 
on  the  simultaneous  processing  of  input  and  output  data  was  adopted. 

Whenever  possible,  the  SODEM  design  was  developed  with  a  module-per-function 
structure  in  order  to  facilitate  system  modification  as  new  concepts  and  technology 
become  available.  These  modules  will  be  implemented  in  an  event-driven,  multiprogram¬ 
ming  environment  to  take  advantage  of  input/output  parallelism,  thereby  improving 
overall  system  response  parameters. 

Finally,  it  was  decided  to  make  the  SODEM  as  transparent  to  the  user  as  possible.  In 
most  cases,  the  SODEM  would  be  added  to  an  already-existing  data  base  management 
system  as  a  front  end.  It  should  in  no  way  interfere  with  or  alter  normal  svstem  operation 
and  its  presence  should  only  be  apparent  when  its  special  features  are  called  for. 

Functional  Description 

The  following  functional  description  of  the  SODEM  is  preliminary  and  intended  to 
give  the  details  needed  to  make  further  definition  and  prototyping  possible. 

The  SODEM  design  is  based  on  the  assumption  that  the  host  system  hardware 
environment,  through  which  it  interfaces  to  the  personnel  data  base,  will  be  similar  to  the 
Navy's  PASS/SDS  system.  In  such  a  system,  the  master  data  base  is  maintained  at  a 
central  site  and  remote  host  processors  (RHPs)  communicate  with  the  central  site.  Field 
transactions  are  made  at  terminals  connected  to  the  RHPs  through  multiplexing  systems. 

One  design  approach  would  be  to  implement  SODEM  software  in  the  RHPs,  thus 
eliminating  the  need  for  additional  hardware.  While  this  might  seem  to  be  an  economical 
idea,  it  is  technically  infeasible  because  host  processing  activities  already  require  all 
available  CPU,  memory,  and  peripheral  resources.  Instead,  the  proposed  SODEM  would  be 
a  hardware/software  entity  interposed  between  the  RHPs  and  the  operator  terminals  to 
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intercept  and  translate  communications  between  RHPs  and  operators.  In  this  configura¬ 
tion,  the  SODEM  could  provide  its  additional  capabilities  to  the  operator  without  using 
host  processor  resources  or  time. 

Hardware  Specifications 

Specifically,  SODEM  will  consist  of  a  microcomputer  system  with  at  least  64K  bytes 
of  random  access  memory,  vectored  interrupts,  and  a  real-time  clock  for  timing  purposes. 
On-line  storage  will  be  provided  by  floppy  disks,  Winchester-type  fixed-media  disks,  or  a 
combination  of  both.  Communications  will  be  via  serial  line  interfaces  (RS  232)  to  both 
the  host  system  and  to  the  operator's  terminal.  To  the  operator,  the  SODEM  will  look  like 
an  RHP  with  advanced  features;  to  the  RHP,  the  SODEM  will  look  like  an  operator 
terminal.  The  hardware  configuration  is  diagrammed  in  Figure  4. 


MAPTIS 
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JUMPS 

Central 

Sites 


Figure  4.  SODEM  hardware  configuration. 


Software  Specifications 

Again,  assumptions  about  the  host  software  environment  are  based  on  PASS/SDS.  In 
such  a  system,  data  base  management  software  allows  personnel  to  add,  modify,  and 
delete  records,  perform  queries,  and  generate  reports.  The  operator  interface  is  provided 
through  screen-oriented  terminal  I/O  software  that  presents  CRT  screens  of  information, 
including  menus  and  forms,  to  the  operator  and  allows  the  operator  to  enter,  examine,  and 
modify  the  currently  relevant  data. 

Such  a  system  allows  two  forms  of  SODEM  interfaces  to  be  considered.  In  the  first, 
no  modification  would  be  required  to  their  host  software.  Instead,  the  SODEM  would 
emulate  the  operator,  accepting  screens  of  display  information  and  returning  input  data  in 
the  form  the  operator  would  normally  enter  it.  In  the  second  scheme,  modifications  would 
be  required  to  the  host's  terminal  I/O  software  which  would  then  send  and  receive 
internally  coded  information  to  and  from  the  SODEM. 
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The  first  scheme  eliminates  the  need  for  host  modification  at  the  cost  of  increased 
complexity  of  SODEM  software.  The  second  economizes  SODEM-host  communication 
while  requiring  possibly  significant  changes  to  host  software.  The  specific  requirements 
of  each  application  will  have  to  be  taken  into  account  in  the  development  of  prototype 
.iixl  i)|M*r.iliofi.il  SOnPMS. 

The  SODEM  will  be  a  modular,  real-time,  multiprogramming  system,  controlled  by  a 
supervisory  module.  Figure  5  illustrates  the  overall  organization  of  the  modules. 
Modules,  called  procedures  here,  will  communicate  via  a  shared  portion  of  dynamic 
memory  that  will  also  be  used  for  storage  of  information  relating  to  the  current  terminal 
session. 


Figure  5.  Organization  of  SODEM  software  modules. 


Hardware  interrupts  will  provide  the  most  basic  level  of  procedure  synchronization. 
These  interrupts  will  be  due  to  I/O  operations  of  the  operator's  terminal,  the  host  system 
interface,  and  the  on-line  disk  subsystems.  In  addition,  timing  interrupts  will  be 
generated  by  the  real-time  clock. 

At  the  functional  level,  the  SODEM  will  be  considered  to  be  event-driven,  where 
functional  procedures  respond  to  external  or  internal  events  to  provide  appropriate 
processing.  Events  will  include  the  completion  of  an  I/O  operation,  such  as  receipt  of  a 
termination  character  following  operator  input  of  a  data  item  or  the  display  of  the  final 
character  in  a  prompt  or  error  message.  Another  class  of  events  will  consist  of  procedure 
completions.  It  will  be  the  responsibility  of  each  processor  to  detect  and  flag  certain 
kinds  of  events  so  that  the  supervisor  procedure  may  invoke  other  procedures  to  service 
these  events.  In  addition,  the  procedure  that  flags  an  event  may  generate  a  message 
about  that  event  to  inform  the  invoked  procedures  about  its  nature  and  characteristics. 

At  any  given  time,  several  procedures  may  be  attempting  to  process  an  event 
simultaneously.  One  procedure  may  be  attempting  to  display  an  error  message  to  the 
operator,  another  may  be  attempting  to  read  input  from  the  host,  and  still  another  may  be 
in  the  process  of  computing  a  performance  measure.  These  procedures  would  then  be  said 
to  be  in  competition  for  SODEM  resources.  In  some  cases,  such  activities  could  take 
place  in  parallel,  as  when  two  independent  I/O  processes  are  in  progress.  Many  times, 
however,  as  with  the  use  of  the  CPU,  sequential  processing  must  be  enforced.  The 
supervisor  module  (SUP)  will  arbitrate  among  competing  procedures  and  allocate 
resources  in  accordance  with  a  priority  scheme. 

The  arbitration  process  may  be  described  with  regard  to  how  the  supervisor  will  deal 
with  certain  classes  of  procedures.  SUP  will  maintain  a  procedure  table  that  lists  the 
characteristics  of  each  procedure  of  SODEM.  Most  procedures  will  initially  be  in  an 
inactive  state.  Inactive  procedures  are  those  that  are  waiting  for  an  event  to  occur,  as  an 
error  detection  procedure  would  need  to  wait  for  the  completion  of  operator  input.  For 
each  inactive  procedure  entry  in  the  procedure  table,  there  will  be  reference  to  the 
event(s)  being  waited  on. 

When  an  event,  such  as  an  I/O  or  procedure  completion,  occurs,  SUP  will  search  the 
procedure  table  to  see  if  any  procedures  are  waiting  on  that  event.  If  so,  those 
procedures  will  become  active,  eligible  to  compete  with  others  for  SODEM  resources. 
They  will  also  be  given  a  priority  that  will  be  used  in  the  arbitration  process.  Similarly, 
procedures  that  have  been  completed  will  be  declared  inactive  in  the  procedure  table  and 
will  no  longer  compete  for  resources  until  their  event  occurs  again. 

Of  the  active  procedures,  only  a  subset  may  be  allowed  to  execute.  While  the  I/O 
handlers  will  respond  immediately  to  interrupts  and  will  therefore  not  be  under  direct 
control  of  SUP,  only  a  single  procedure  will  be  allowed  to  execute.  The  executing 
procedure  will  be  the  active  procedure  with  the  highest  priority.  Priority  will  be  dynamic 
and  the  priority  of  a  given  procedure  will  depend  upon  its  immediate  importance  in 
satisfying  overall  system  objectives. 

Those  active  procedures  not  executing  will  be  termed  suspended.  For  example,  a 
procedure  will  be  suspended  if  it  is  waiting  for  an  I/O  process  to  complete,  if  it  is  waiting 
for  a  specific  event  to  occur,  or  if  it  is  simply  preempted  by  a  higher-priority  procedure. 

While  SUP  will  oversee  I/O  operations  and  control  procedure  states,  the  actual 
sequencing  of  the  SODEM  will  be  performed  cooperatively  by  the  procedures  themselves. 
This  feature  will  allow  flexibility  in  applying  the  SODEM  to  different  data  base  systems. 


The  function  and  major  characteristics  of  ail  components  of  the  SODEM  are 
described  in  Appendix  A. 


CONCLUSIONS 

Effectiveness  of  the  Distributed  System 

A  common  but  nevertheless  important  finding  was  that  user  acceptance  is  an  enabling 
requirement  for  the  design  of  human-computer  systems.  Without  user  acceptance, 
excellence  of  design  in  other  areas  can  be  largely  wasted  effort.  The  distributed  system 
received  user  acceptance  while  the  self-contained  system  did  not.  This  result  is  clearly 
due  to  two  design  features: 

1.  A  computer  system  must  aid  the  user  in  performing  the  work  assignment,  and 
preferably  reduce  the  work  load.  Furthermore,  as  the  study  of  system  timing  parameters 
(Williges  &  Williges,  1982)  indicates,  system  response  time  must  meet  stringent  user 
standards. 

2.  The  DODES  offered  a  clear  advantage  in  terms  of  office  efficiency.  Changes  to 
previously  entered  forms  could  be  made  without  retyping  the  entire  form,  while  use  of  the 
manual  method  required  complete  retyping  for  even  the  simplest  changes.  The  keystroke 
reduction  made  possible  by  DODES  was  a  major  factor  in  its  having  achieved  acceptance 
by  the  users. 

Manual  Review  Requirements 

An  important  feature  of  the  current  application  of  automation  is  that  a  significant 
number  of  data  entry  errors  can  be  automatically  detected.  However,  it  is  clear  that  not 
all  errors  can  be  detected  automatically.  The  designer  of  computerized  systems  for  data 
entry  should  therefore  consider  the  requirement  for  manual  review.  Possibly  because  of 
the  ease  of  operator  review  on  the  test  system,  the  number  of  undetected  errors  was  less 
than  experienced  with  the  manual  typewriter  method.  Nevertheless,  additional  design 
attention  to  manual  review  needs  would  probably  result  in  further  improvement.  In 
particular,  methods  to  incorporate  review  by  individuals  other  than  the  one  who  entered 
the  data  should  be  pursued. 

Office  Automation 


The  primary  emphasis  of  the  current  program  was  on  accuracy,  timeliness,  and 
usability  of  source  data  entry.  However,  it  was  evident  that  the  savings/investment  ratio 
could  be  improved  if  computers  were  used  for  more  than  just  data  entry.  Also,  it  would 
be  difficult  to  achieve  user  acceptance  of  a  device  that  could  only  be  used  for  data  entry. 
A  minimum  system,  therefore,  would  permit  data  entry,  retrieval  of  selected  data,  and 
automation  of  routine  management  reports.  An  expanded  view  of  the  use  of  automation, 
and  probably  one  closer  to  optimum  cost  effectiveness,  would  provide  comprehensive 
automation  for  personnel  functions  so  that  data  entry  would  take  place  in  the  course  of 
routine  office  activities. 

Effectiveness  of  the  Approach  Used  in  this  Research 

The  approach  used  in  this  research  was  a  combination  of  field  and  laboratory  testing. 
The  dominant  feature,  however,  was  the  use  of  a  test  device  in  a  working  field  office.  It 
therefore  allowed  identification  of  "real"  problems  as  they  arose  in  a  typical  Navy  office 
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environment.  There  is  really  no  substitute  for  this  approach,  for  Navy  personnel  cannot 
be  made  available  for  extensive  laboratory  testing,  nor  could  an  office  environment  be 
economically  simulated  in  a  laboratory. 


The  problems  of  user  acceptance  have  already  been  described  and  represent  a  major 
difficulty  with  the  combined  field/laboratory  testing  approach.  The  field  office  is  an 
inappropriate  environment  for  testing  marginal  designs.  If  the  test  device  doesn't  offer 
sufficient  advantage,  it  won't  be  used  by  office  personnel.  Consequently,  research 
personnel  must  ensure  that  a  candidate  SODEM  is  refined  in  the  laboratory  to  the  point 
where  its  application  in  the  field  office  will  clearly  represent  an  improvement  over 
current  office  operation. 

Guidelines  for  System  Designers 

i  The  observations  and  findings  of  this  research  effort  can  be  summarized  in  the 
following  guidelines  for  the  design  of  office  data  entry  systems: 

1.  Minimize  system  response  time— A  hardware/software  design  goal  should  be  to 
keep  response  time  to  less  than  5  seconds. 

2.  Maintain  adequate  keyboard  echo  rates— The  results  of  the  Williges  and  Williges 
(1982)  study  indicate  that  echo  rates  should  be  less  than  0.75  seconds. 

3.  Provide  examples  of  inputs— Operators  are  less  prone  to  make  input  errors  when 
the  system  provides  prompts  with  examples  illustrating  appropriate  syntax. 

4.  Require  manual  review— User  input  should  be  reechoed  in  an  appropriate  format 
for  review  before  it  is  incorporated  into  the  data  base. 

5.  Involve  the  end-users— Throughout  the  system  life  cycle,  comments  and  sugges¬ 
tions  should  be  solicited  from  personnel  who  are  using  the  system. 


RECOMMENDATIONS 

1.  Using  the  preliminary  specifications  provided  in  this  report,  develop  an  advanced 
SODEM  for  use  at  operational  Source  Data  System  (SDS)  sites.  This  would  provide  a  way 
to  assess  the  validity  and  cost-effectiveness  of  the  proposed  design  and  will  also  provide  a 
basis  for  enhancing  the  designs  of  current  and  future  SDS  research  programs. 

2.  The  query-response  dialog  should  be  studied  to  find  ways  of  improving  time 
performance.  A  query-response  dialog  was  needed  to  provide  for  user  control  over  system 
functions  such  as  user  log-in  name,  review,  change,  print,  and  the  like.  The  dialog 
selected  proved  to  be  slow  and  errorprone;  that  is,  it  provided  higher  overhead  time  than 
the  authors  desired. 

3.  Field  office  operations  should  be  studied  further  so  that  non-data-entry  SODEM 
modules  may  be  developed  that  will  enhance  the  cost-effectiveness  of  the  total  source 
data  system. 
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SOURCE  DATA  ENTRY  MODULE  (SODEM)  COMPONENT  DESCRIPTION 


This  appendix  describes  the  function  and  major  characteristics  of  each  component  of 
the  proposed  SODEM  (see  Figure  5,  page  21). 

Interprocedure  Buffer  (IPB) 

1.  Function.  The  IPB  will  serve  as  a  communication  link  between  the  procedures 
and  a  shared  dynamic  storage  region.  It  will  ultimately  be  under  control  of  the  supervisor 
module  (SUP). 


2.  Uses.  The  IPB  will  be  used  as  a  buffer  for  keyboard  input,  display  output,  host 
system  I/O,  and  disk  I/O.  Messages  associated  with  events  and  sent  from  procedure  to 
procedure  will  be  contained  in  the  IPB  but  pointers  referring  to  the  messages  will  be,  in 
actuality,  the  entities  passed  back  and  forth.  Information  about  the  current  state  of  the 
SODEM  will  be  maintained  in  the  IPB  by  SUP.  In  addition,  a  portion  of  the  IPB  will  be 
used  to  store  a  complete  record  of  the  current  transaction  being  processed  by  the 
operator  so  that  reference  may  be  made  to  previous  occurrences  in  the  transaction  and 
the  context  of  the  transaction  may  be  recovered  if  a  host  system  failure  should  occur. 

Supervisor  Module  (SUP) 

1.  Function.  SUP  will  provide  complete  software  control  over  the  SODEM  through 
the  resource  allocation  process  described  on  page  22.  It  will  maintain  information  in  the 
IPB  concerning  operations  in  progress  so  that  other  procedures  may  determine  the  context 
of  operator  and  host  system  actions. 

2.  Procedure  table.  SUP  will  maintain  a  table  listing  each  procedure  and  its 
current  characteristics.  Included  in  the  table  will  be  the  procedure's  name,  its  state 
(inactive,  active,  executing,  suspended),  its  priority,  the  event(s)  the  procedure  is  waiting 
on,  the  entry  point  of  the  procedure,  and  a  scratch  area  for  any  necessary  pointers  to 
related  messages  that  the  procedure  may  ac<|uire  when  executing. 

3.  Events.  In  the  SODEM  context,  the  term  "event"  denotes  I/O  or  module 
completion.  Operationally,  an  event  will  be  detected  by  an  individual  procedure,  which 
will  then  place  a  code  for  that  event  in  one  of  the  CPU's  general  purpose  registers  and,  if 
a  message  is  to  be  associated  with  the  event,  a  pointer  to  the  message  in  another  register. 
The  procedure  will  then  trap  to  SUP,  which  will  then  perform  the  arbitration  process. 
Specifically,  SUP  will  activate  and  deactivate  procedures  by  making  appropriate  changes 
to  the  procedure  table.  The  highest  priority  active  procedure  will  be  declared  as 
executing,  and  the  other  active  procedures  will  be  suspended.  When  all  bookkeeping  is 
completed,  SUP  will  branch  to  the  executing  procedure,  which  will  retain  control  of  the 
CPU  until  the  next  event  occurs. 

The  I/O  handlers  will  be  connected  to  the  interrupt  vectors  of  the  CPU  and  will 
provide  all  I/O  processing  for  the  SODEM.  They  will  be  invoked  by  requests  from  the 
procedures. 

Terminal  Handler  (TH) 

1.  Function.  TH  will  perform  all  terminal  I/O  operations,  reading  input  from  the 
keyboard,  and  displaying  output  on  the  CRT.  Inputs  from  the  keyboard  will  be  placed  in  a 
buffer  in  the  IPB  and  a  pointer  to  the  buffer  will  be  passed  to  the  requesting  procedures. 


In  addition,  TH  will  read  the  real-time  clock  and  time-stamp  the  input  character-by¬ 
character  so  that  information  regarding  operator  performance  may  be  derived  by 
subsequent  procedures.  Requests  for  display  output  will  be  accompanied  by  pointers  to 
the  text  to  be  displayed  that  will,  again,  be  located  in  a  buffer  in  the  IPD. 

2.  Interrupts.  TH  will  respond  to  keyboard  and  display  interrupts. 

3.  Events  flagged.  TH  will  detect  and  flag  the  initiation  and  completion  of 
operator  input  and  tne  completion  of  display  output. 

4.  Potential  refinements.  Initial  SODEM  prototypes  will  include  standard 
keyboard/CRT  I/O  as  described  above.  After  initial  studies,  it  will  be  simple  to  modify 
TH  to  allow  cursor  positioning  via  key,  joystick,  or  trackball  control  to  provide  simpler 
and  more  direct  means  of  operator  control  of  data  entry.  Similarly,  the  modular  nature  of 
the  SODEM  will  allow  the  incorporation  of  a  TH  with  touch  panel  and  voice  I/O 
capabilities. 

Host  Handler  (HH) 

1.  Function.  The  function  of  HH  will  be  analogous  to  that  of  TH,  but  HH  will 
perform  I/O  from  and  to  the  host  system. 

2.  Interrupts.  HH  will  respond  to  interrupts  resulting  from  reception  of  a 
transmission  from  the  host  and  from  the  completion  of  transmission  to  the  host. 

3.  Events  flagged.  HH  will  notify  SUP  upon  the  completion  of  host  message 
transmission  or  reception. 

Disk  Handler  (DH) 

1.  Function.  All  display  information,  including  prompts,  error  messages,  and  HELP 
screens,  will  be  stored  on  disk.  Additionally,  a  number  of  SODEM  data  bases,  such  as 
operator  performance  information,  translations  tables,  and  procedural  rules  will  be  disk- 
based.  DH  will  perform  all  I/O  operations  necessary  to  access  this  information. 

2.  Interrupts.  DH  will  process  disk  read  and  write  interrupts. 

3.  Events  flagged.  When  a  complete  I/O  operation,  such  as  the  recovery  of  an 
entire  screen  image  irom  disk,  has  been  performed,  DH  will  flag  a  disk  I/O  event.  SUP 
will  then  invoke  the  procedure  that  requested  the  operation.  The  remaining  SODEM 
components  are  the  procedures  that  perform  the  substantive  SODEM  functions.  For  each 
procedure,  its  function  inputs,  outputs,  the  events  it  detects  and  flags,  and  the  events  it 
waits  for  will  be  discussed.  Other,  procedure-specific  characteristics  will  be  presented  in 
selected  cases. 

Operator  Monitor  Procedure  (OMP) 

1.  Function.  OMP  will  maintain  an  operator  profile,  a  record  of  operator  activities 
and  performance,  throughout  a  transaction  and  between  transactions.  This  profile  will  be 
used  by  other  procedures  in  adaptive  error  detection  and  correction,  and  in  the  selection 
of  appropriate  levels  of  prompt  and  message  detail  based  on  operator  behavior.  OMP  will 
record  response  time,  typing  time,  error  rates,  and  characteristics  of  operator  errors  such 
as  frequency  based  on  error  type  and  so  on. 
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2.  Inputs.  Performance  measurement  and  recording  by  OMP  will  be  based  on  the 
time-stamped  operator  input  provided  by  TH.  In  addition,  display  codes  from  which  DH 
selects  appropriate  information  to  display  will  be  provided  by  the  host  interface  procedure 
(HIP)  so  that  OMP  is  aware  of  the  display  that  the  operator  is  responding  to. 

3.  Outputs.  OMP  will  write  information  about  the  operator  to  the  operator  profile 
data  base. 

4.  Invoking  events.  OMP  will  flag  an  event  upon  its  completion. 

Input  Interpretation  Procedure  (IIP) 

1.  Function.  Operator  input  may  be  in  the  form  of  data  during  a  transaction  or  it 
may  be  a  command  to  the  host  system  or  a  request  for  a  SODEM  job  performance  aid.  IIP 
scans  operator  input  and  invokes  the  appropriate  procedure.  The  host  interface  procedure 
(HIP)  is  requested  when  data  or  a  host  command  is  input.  Appropriate  job  performance 
aids  or  auxiliary  function  procedures  are  invoked  when  the  operator's  command  calls  for 
their  services. 

2.  Inputs.  IIP  operates  on  operator  input,  provided  by  TH. 

3.  Outputs.  Messages  must  occasionally  be  sent  to  the  invoked  procedures. 

4.  Invoking  events.  IIP  is  invoked  upon  the  receipt  of  operator  input. 

5.  Events  flagged.  Requests  for  the  initiation  of  procedures  will  be  the  events 
flagged  by  OP. 

6.  Data  base  accessed.  A  table  relating  commands  to  appropriate  procedures  will 
be  used  by  IIP.  If  sufficiently  compact,  this  table  will  be  retained  in  memory;  otherwise, 
it  will  be  kept  on  disk  and  read  via  DH. 

Host  Interface  Procedure  (HIP) 

1.  Function.  HIP  will  translate  inputs  from  the  host  system  to  sequences  of  SODEM 
activities.  In  addition,  HIP  will  translate  operator  inputs  for  transmissions  to  the  host. 

2.  Outputs.  HIP  will  send  appropriately  translated  and  formatted  output  to  the  host 
via  HH. 


3.  Invoking  events.  HIP  will  be  initiated  upon  the  occurrence  of  events  signaling 
receipt  of  prompts,  menus,  etc.  from  the  host  via  HH.  It  will  typically  initiate  the 
sequences  of  activities  designed  to  provide  the  input  necessary  for  the  host  and  suspend 
itself  until  operator  input  is  received. 

4.  Events  flagged.  In  addition  to  flagging  its  own  completion,  HIP  will  request 
other  operations,  such  as  information  display  and  the  acquisition  of  operator  input. 

5.  Data  bases  accessed.  HIP  will  use  two  data  bases.  The  first  will  be  a  translation 
table  relating  operator  commands  to  appropriate  host  commands.  The  second  will  be  a  set 
of  "programs"  necessary  to  convert  host  prompts  to  sequences  of  SODEM  activities.  For 
instance,  given  a  particular  form  that  must  be  completed  by  the  operator,  the  associated 
"program"  would  provide  a  sequence  of  prompts  to  display  to  the  operator  to  acquire  the 
necessary  information. 
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6.  Operator  error  prevention.  Within  HIP  lie  the  first  opportunities  for  the 
reduction  of  operator  error  in  SODEM.  The  displays  that  HIP  causes  to  be  presented  to 
the  operator  can  greatly  aid  in  eliminating  input  errors  before  they  occur. 

All  data  prompts  will  provide  clear  explanations  of  the  data  required.  An  example 
will  be  included  for  each  type  of  datum  to  be  entered.  Where  appropriate,  a  menu  of 
acceptable  responses  will  be  given.  In  these  cases,  the  operator  will  select  the  entry  from 
the  menu  not  by  typing  the  entire  entry  or  a  numeric  cede,  but  instead  by  typing  an 
allowable  abbreviation,  highlighted  in  the  menu  by  capital  letters,  underlining,  or  reverse 
video. 

Error  Detection  Procedure  (EDP) 

1.  Function.  EDP  will  detect  and  flag  errors  in  the  data  entered  by  the  operator. 

2.  Input.  This  procedure  will  process  operator  input  provided  through  TH. 

3.  Output.  When  no  errors  are  detected  in  the  data,  EDP  will  produce  no  output. 
When  errors  are  detected,  information  concerning  those  errors  will  be  provided  to  the 
error  correction  procedure  (ECP). 

4.  Invoking  event.  The  actions  of  EDP  will  begin  when  IIP  has  determined  that  the 
operator  has  entered  data  and  an  event  requesting  error  detection  has  been  flagged. 

5.  Events  flagged.  When  EDP  detects  no  errors  in  the  entered  data,  it  will  merely 
flag  its  own  completion  event.  When  an  error  is  detected,  it  will  signal  completion  and 
request  the  error  correction  procedure  (ECP). 

4.  Error  detection  methods.  Errors  will  be  detected  by  EDP  in  two  major  ways— by 
independent  datum  checks  and  by  relational  checks.  All  strictly  numeric  data  will  be 
subject  to  range  checks.  When  a  number  is  entered,  it  will  be  compared  with  the 
acceptable  range  and  values  outside  the  range  will  be  flagged.  Other  data  will  be  subject 
to  table  checks.  Input  will  be  tested  to  see  that  alphabetic  characters  are  not  substituted 
for  numeric  characters  and  vice  versa.  When  input  related  to  existing  data  is  entered, 
certain  identifying  information  will  be  compared  with  that  existing  data.  For  example, 
when  a  serviceman's  record  is  to  be  updated,  the  social  security  number  will  be  compared 
with  the  data  base.  If  no  match  if  found,  an  error  will  be  flagged.  Word  entries,  such  as 
the  names  of  persons  and  places,  will  be  tested  for  spelling  accuracy  against  an  internal 
vocabulary. 

Within  a  given  transaction,  such  as  the  completion  of  a  form  to  update  personnel 
records,  a  number  of  relational  data  checks  will  be  made.  Dates  will  be  compared  against 
the  current  date.  Disparities  between  date  of  birth,  date  of  enlistment,  date  of  marriage, 
and  dates  future  actions  are  to  be  taken  will  be  sought  for.  In  each  case,  certain 
minimum  thresholds  (to  be  determined  on  case-specific  base;'  will  be  used.  Spelling 
consistency  tests  will  be  made  on  word  entries  such  as  names  and  addresses.  In  the  case 
of  each  relational  check,  a  table  of  relational  links  within  a  transaction  will  be  maintained 
by  EDP  to  be  used  in  the  detection  process. 

In  addition  to  these  error  detection  methods,  EDP  will  help  reduce  errors  by  a 
suitable  redefinition  of  errors.  In  most  data  entry  systems,  rather  rigid  format  is  often 
required  with  respect  to  certain  items  such  as  dates,  times,  codes,  and  numeric  values. 
By  allowing  more  flexibility  in  such  items,  time  required  for  operator  correction  of  errors 
can  be  minimized.  In  a  case  where  an  operator  enters  the  data  in  an  incorrect  yet 


recognizable  format,  EDP  will  flag  it  as  a  potential  error  and  request  the  error  correction 
procedure  to  correct  it  with  minimal  or  no  operator  intervention. 

Error  Correction  Procedure  (ECP) 

1.  Function.  ECP  will  correct  data  entry  errors  both  automatically  and  through 
operator  assistance. 

2.  Inputs.  The  inputs  to  ECP  will  be  operator  input  via  TH  and  error  information, 
as  provided  by  EDP. 

3.  Outputs.  ECP  will  present  error  messages  and  data  prompts  to  the  operator  via 
TH.  When  the  data  in  error  has  been  corrected,  it  will  be  passed  to  the  data  reformatting 
procedure  (DRP). 

4.  Invoking  events.  This  procedure  will  be  initially  invoked  upon  a  request  for  error 
correction  by  EDP.  Wfien  corrections  are  being  made  with  operator  assistance,  it  will 
subsequently  suspend  itself  and  wait  for  operator  input  to  resume. 

5.  Events  flagged.  When  an  error  has  been  corrected,  ECP  will  flag  its  completion 
and  request  the  execution  of  the  data  reformatting  procedure. 

6.  Error  correction  methods.  The  simplest  form  of  error  correction  will  involve 
operator  assistance.  ECP  will  request  the  display  of  an  error  message  that  explains  the 
nature  of  the  error  and  how  it  is  to  be  corrected.  The  operator  will  be  required  to  reenter 
only  that  data  which  is  in  error.  In  no  case  will  the  operator  be  requested  to  reenter 
correct  data.  In  many  cases,  this  will  mean  that  the  CRT  cursor  will  be  positioned  at  the 
incorrect  portion  of  the  entry  and  only  a  few  characters  will  need  to  be  typed.  When 
information  about  operator  experience  with  the  SODEM  is  available  from  the  operator 
profile  data  base,  the  level  of  detail  of  the  error  messages  and  data  prompts  will  be  keyed 
to  that  information.  Relatively  new  users  will  be  given  extensive  error  diagnostics  and 
instructions  on  corrections.  Experienced  users  will  be  presented  with  concise  messages 
intended  to  refresh  their  memories  about  data  entry  procedures. 

In  the  cases  of  some  errors,  automatic  correction  by  ECP  will  be  possible.  For 
example,  when  punctuation  is  omitted  from  an  entry,  it  will  be  scanned  for  proper  overall 
format  and  appropriate  punctuation  will  be  inserted.  When  a  date  is  entered  in  numeric 
format  instead  of  the  use  of  an  alphabetic  abbreviation  for  month,  the  conversion  will  be 
made.  If  the  operator  profile  data  base  permits,  records  will  be  kept  of  habitual  errors  of 
individual  operators,  along  with  the  appropriate  corrections.  When  sufficient  data  are 
gathered  on  these  errors,  the  corrections  will  be  made  automatically.  One  important 
issue  that  remains  unresolved  by  this  research,  however,  is  whether  or  not  the  operator 
should  be  called  upon  to  validate  corrections  made  automatically.  Prototype  testing  will 
be  required  to  answer  this  question. 

Data  Reformatting  Procedure  (DRP) 

1.  Function.  DRP  will  convert  data  to  a  form  acceptable  to  the  host  system.  In 
many  cases,  no  reformatting  will  be  necessary.  In  others,  abbreviations  will  be  expanded, 
codes  will  be  interpreted,  and  punctuation  will  be  inserted  or  changed. 

2.  Input.  TH  will  provide  the  operator  input  used  by  DRP. 

3.  Output.  DRP  will  produce  correctly  formatted  data  for  the  host  system. 
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4.  Invoking  event.  DRP  will  be  invoked  by  requests  from  EDP  and  ECP. 

5.  Events  flagged.  An  event  will  be  flagged  by  DRP  upon  its  completion. 
Additionally,  DRP  will  request  HH  to  send  the  data  to  the  host. 

Job  Performance  Aid  (3PA)  Procedures 

The  SODEM  will  incorporate  a  number  of  JPAs,  their  specific  natures  depending  on 
the  particular  SODEM  application.  The  initial  prototypes  will  include  a  subset  of  the 
following  JPAs  as  procedures. 

1.  On-line  HELP  directives.  The  most  basic  JPA  incorporated  in  the  SODEM  will 
be  a  HELP  system  that  provides  information  about  particular  commands  and  data 
elements.  HELP  will  be  invoked  by  the  operator  by  typing  a  question  mark  or  the  word 
"help"  in  response  to  a  SODEM  prompt.  When  this  is  scanned  by  IIP,  the  HELP  procedure 
will  be  invoked  to  display  screens  of  information  explaining  the  matter  in  question  to  the 
operator.  The  HELP  procedure  will  use  the  current  state  information  in  the  IPB  to 
determine  what  the  operator  is  asking  about.  Later  versions  will  use  information  from  the 
operator  profile  data  base  to  determine  what  level  of  detail  is  required  by  the  operator. 
Like  the  error  messages  and  prompts  of  ECP,  the  HELP  messages  for  inexperienced  users 
will  be  quite  extensive  while  those  for  experts  will  be  concise.  Advanced  versions  of 
HELP  will  key  the  level  of  detail  to  the  operator's  experience  with  the  particular  type  of 
command  or  transaction  in  progress  rather  than  just  a  general  level  of  experience.  An 
extension  of  the  HELP  procedure  will  be  one  that  provides  on-line  access  to  procedural 
directives,  thereby  eliminating  the  need  for  the  operator  to  break  from  the  transaction  to 
refer  to  hard-copy  documents.  The  operator  will  be  allowed  to  branch  within  the  system 
to  any  manual  required  to  complete  the  transaction  without  losing  any  portion  of  the 
transaction. 

2.  On-line  training.  Operator  performance  assessment  by  OMP  will  provide  a 
diagnostic  tool  to  identify  operator  skill  deficiencies.  These  may  in  turn  be  remedied  by 
an  on-line  training  procedure.  This  procedure  will  provide  tutorial  examples  of  system  use 
and  transaction  processing  and  include  embedded  exercises  and  testing.  Such  features  will 
minimize  the  need  for  intervention  by  supervisory  personnel. 

3.  Scheduling.  A  scheduling  procedure  will  maintain  a  table  of  appointments  and 
deadlines  for  operators  and  remind  them,  in  a  timely  manner,  of  these  obligations. 
Entries  will  be  added  by  the  ooerators  themselves  or  by  supervisory  personnel  via  the  host 
system. 

4.  Computational  aids.  Computations  are  sometimes  necessary  to  complete  data 
entry  casTcs.  A  calculator  procedure  will  be  available  to  compute  numeric  quantities, 
elapsed  time,  and  so  on 

5.  Transaction  suspension/resumption.  Data  entry  transactions  are  often  inter¬ 
rupted  by  higher  priority  tasks.  With  the  use  of  the  SODEM,  when  such  an  event  occurs, 
the  operator  will  invoke  a  transaction  suspension/resumption  procedure  that  will  termi¬ 
nate  the  current  transaction  and  copy  the  transaction  record  in  the  IPB  to  disk  storage.  It 
will  then  make  an  entry  in  the  scheduling  table  to  remind  the  operator  of  the  suspended 
action.  When  the  operator  later  requests  the  resumption  of  that  transaction,  the 
procedure  will  recover  the  record,  re-initiate  the  transaction  automatically,  and  bring  the 
transaction  up  to  its  point  of  interruption.  As  this  is  being  done,  the  information  being 
sent  to  the  lost  will  also  be  displayed  to  the  operator  so  the  transaction  can  be  completed 
with  minimal  difficulty. 


It  will  be  possible  to  incorporate  a  number  of  additional  features  into  the  SODEM. 
Reference  has  been  made  to  operator  performance  assessment,  which  will  be  of  prime 
importance  to  supervisory  personnel  in  data  entry  system  management  and  planning.  An 
auxiliary  function  procedure  could  be  incorporated  in  the  SODEM  to  provide  operator 
performance  reporting  to  authorized  personnel. 


SYSTEM  TIMING  PARAMETER  STUDY 


The  basic  SODEM  concept  is  one  of  a  front-end  module  that  can  provide  (1) 
information  to  the  host  computer  system  as  needed  and  (2)  a  desirable  user  interface. 
There  is  a  limit,  however,  to  the  extent  to  which  a  SODEM  can  provide  user-interface 
characteristics  independent  of  the  host  characteristics.  Timing  characteristics,  for 
example,  are  important  to  the  user,  and  there  is  a  limit  to  the  extent  to  which  SODEM 
can  cover  up  delays  in  transmission  to,  and  processing  by,  the  host  computer  system. 
Consequently,  as  an  augmentation  to  the  function  description  for  SODEM,  a  study  of 
system  timing  parameters  was  performed  for  NAVPERSRANDCEN  (Williges  &  Williges, 
1982).  The  following  is  a  brief  summary  of  some  of  the  salient  features  of  that  study. 

Method 


The  task  was  a  simulation  of  a  Navy  personnel  records-keeping  task  in  which  the 
operator  used  an  interactive  computer  terminal.  The  particular  transaction  was  complet¬ 
ing  a  form  similar  to  the  Navy  pay  order  form  used  to  issue  a  temporary  pay  change. 
Alphanumeric  information  was  entered  into  a  series  of  12  fields;  these  included  items  such 
as  date,  name,  social  security  number,  duty  station,  amount  of  pay,  reason  for  change, 
etc.  Specific  Navy  format  rules  were  followed  for  entering  the  data.  Each  subject  was 
required  to  perform  either  ADD  or  CHANGE  transactions  on  these  records. 

Four  undergraduate  students  were  used  as  subjects.  Four  variables  relating  to  various 
timing  paramters  of  the  computer  system  were  manipulated;  these  included  system  delay 
(SD),  display  rate  (DR),  echo  rate  (ER),  and  buffer  length  (BL).  These  parameters 
controlled  the  delay  time  between  an  operator's  input  and  the  computer  response,  the  rate 
at  which  characters  were  displayed  on  the  display  screen,  the  delay  between  a  keystroke 
and  the  appearance  of  that  character  on  the  screen,  and  the  number  of  characters  that 
could  be  typed  and  held  in  a  buffer  awaiting  display. 

Three  classes  of  measurements  were  taken:  work  sampling,  embedded  performance 
measurement,  and  operator  satisfaction  ratings.  Work  sampling  measurement  consisted  of 
the  analysis  of  what  each  subject  was  viewing  and  doing  based  on  closed-circuit  television 
data.  Embedded  performance  measurement  consisted  of  automatic  analysis  of  typing 
rate,  user  response  time,  user  ready  time,  number  of  ready  responses,  number  of 
character  erasures,  and  checking  time.  Satisfaction  ratings  were  collected  using  a  ten 
point  Likert-type  rating  scale. 

Results 


System  timing  variables  affect  the  amount  of  time  devoted  to  various  aspects  of  the 
task.  The  proportions  of  the  total  time  devoted  to  various  task  components  was  as 
follows: 


Task  Component 


Proportion 


1. 

Viewing  the  keyboard  while  entering  data. 

28.3% 

2. 

Looking  at  the  display. 

26.4% 

3. 

Display/typing. 

23.4% 

4. 

Looking  at  information. 

16.4% 

5. 

Information/typing. 

3.9% 

6. 

Looking  at  keyboard. 

1.7% 

Polynomial  regressions  oi  the  time  spent  in  various  aspects  of  the  task  show  that  the 
operator  spent  increasingly  more  time  viewing  the  display  as  additional  delays  wire 
introduced. 

A  polynomial  regression  plot  of  the  operator's  overall  rating  of  satisfaction  as  a 
function  of  SD  and  ER  showed  that  the  subjects  were  clearly  satisfied  with  the  fastest  SD 
and  ER,  but  their  satisfaction  decreased  rapidly  as  timing  delays  were  introduced.  The 
subjects  expressed  almost  total  dissatisfaction  when  SD  was  greater  than  5  seconds  and 
ER  was  more  than  0.75  seconds  delayed. 

To  estimate  the  underlying  behavioral  dimensions,  a  principal  components  analysis 
was  conducted,  leading  to  identification  of  three  principal  components:  production, 
waiting,  and  planning.  The  component  named  production  was  most  heavily  weighted  on 
typing  rate  and  operator  ratings  of  echo  rate,  buffer  length,  speed,  accuracy,  and  overall 
satisfaction.  The  waiting  dimension  consists  of  metrics  such  as  time  spent  viewing  the 
display,  field  entry  and  next  field  ready  times,  operator  ready  responses,  and  operator 
ratings  of  system  delay.  The  planning  dimension  included  variables  such  as  time  spent  by 
the  operator  viewing  the  display  while  typing,  next  field  and  field  entry  user  response 
time,  and  operator  rating  of  the  cueing  tones.  A  multivariate  response  surface  for 
production  was  generated.  It  showed  that  production  activity  is  highest  at  the  shortest 
system  delay  and  keyboard  echo  rate,  and  as  delays  are  introduced,  production  decreases 
markedly.  For  further  discussion  concerning  the  principal  components  analysis  and  the 
three  components  identified,  see  Williges  and  Wiiliges  (1982). 

It  is  clear  from  these  data  that  system  delay  parameters  have  marked  effect  on 
operator  performance,  and  that  minimum  delay  is  necessary  for  maximum  data  entry 
performance.  It  follows  that  the  success  of  SODEM  and  SDS  will  depend  on  fast  response 
from  the  host  computer.  Relatively  small  system  delays  will  have  serious  consequences  in 
terms  of  task  performance  and  acceptance. 
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